<!DOCTYPE html>
<html >
<head>
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
<meta name="generator" content="hevea 2.32">
<link rel="stylesheet" type="text/css" href="omniORBpy.css">
<title>Python language mapping issues</title>
</head>
<body >
<a href="omniORBpy002.html"><img src="previous_motif.svg" alt="Previous"></a>
<a href="index.html"><img src="contents_motif.svg" alt="Up"></a>
<a href="omniORBpy004.html"><img src="next_motif.svg" alt="Next"></a>
<hr>
<h1 id="sec33" class="chapter">Chapter&#XA0;3&#XA0;&#XA0;Python language mapping issues</h1>
<p>omniORBpy adheres to the standard Python mapping&#XA0;[<a href="omniORBpy013.html#pythonmapping">OMG01b</a>],
so there is no need to describe the mapping here. This chapter
outlines a number of issues which are not addressed by the standard
(or are optional), and how they are resolved in omniORBpy.</p>
<h2 id="sec34" class="section">3.1&#XA0;&#XA0;Narrowing object references</h2>
<p>
<a id="sec:narrowing"></a></p><p>As explained in chapter&#XA0;<a href="omniORBpy002.html#chap%3Abasics">2</a>, whenever you receive an
object reference declared to be base <span style="font-family:monospace">CORBA::Object</span>, such as
from <span style="font-family:monospace">NamingContext::resolve()</span> or
<span style="font-family:monospace">ORB::string_to_object()</span>, you should narrow the reference to
the type you require. You might think that since Python is a
dynamically typed language, narrowing should never be necessary.
Unfortunately, although omniORBpy often generates object references
with the right types, it cannot do so in all circumstances.</p><p>The rules which govern when narrowing is required are quite complex.
To be totally safe, you can <em>always</em> narrow object references to
the type you are expecting. The advantages of this approach are that
it is simple and that it is guaranteed to work with all Python ORBs.</p><p>The disadvantage with calling narrow for all received object
references is that much of the time it is guaranteed not to be
necessary. If you understand the situations in which narrowing
<em>is</em> necessary, you can avoid spurious narrowing.</p>
<h3 id="sec35" class="subsection">3.1.1&#XA0;&#XA0;The gory details</h3>
<p>When object references are transmitted (or stored in stringified
IORs), they contain a single type identifier string, termed the
<span style="font-style:italic">repository id</span>. Normally, the repository id represents the most
derived interface of the object. However, it is also permitted to be
the empty string, or to refer to an interface higher up the
inheritance hierarchy. To give a concrete example, suppose there are
two IDL files:</p><div class="lstlisting"><span style="font-size:small"><span style="font-style:italic"><span style="font-size:small">// a.idl</span></span></span><span style="font-size:small">
</span><span style="font-size:small"><span style="font-weight:bold">module</span></span><span style="font-size:small"> </span><span style="font-size:small">M1</span><span style="font-size:small"> {</span><span style="font-size:small">
</span><span style="font-size:small">  </span><span style="font-size:small"><span style="font-weight:bold">interface</span></span><span style="font-size:small"> </span><span style="font-size:small">A</span><span style="font-size:small"> {</span><span style="font-size:small">
</span><span style="font-size:small">    </span><span style="font-size:small"><span style="font-weight:bold">void</span></span><span style="font-size:small"> </span><span style="font-size:small">opA</span><span style="font-size:small">();</span><span style="font-size:small">
</span><span style="font-size:small">  };</span><span style="font-size:small">
</span><span style="font-size:small">};</span></div><div class="lstlisting"><span style="font-size:small"><span style="font-style:italic"><span style="font-size:small">// b.idl</span></span></span><span style="font-size:small">
</span><span style="font-size:small"><span style="font-weight:bold">#include</span></span><span style="font-size:small"> </span><span style="font-size:small"><span style="font-size:small">"a.idl"</span></span><span style="font-size:small">
</span><span style="font-size:small"><span style="font-weight:bold">module</span></span><span style="font-size:small"> </span><span style="font-size:small">M2</span><span style="font-size:small"> {</span><span style="font-size:small">
</span><span style="font-size:small">  </span><span style="font-size:small"><span style="font-weight:bold">interface</span></span><span style="font-size:small"> </span><span style="font-size:small">B</span><span style="font-size:small"> : </span><span style="font-size:small">M1</span><span style="font-size:small">::</span><span style="font-size:small">A</span><span style="font-size:small"> {</span><span style="font-size:small">
</span><span style="font-size:small">    </span><span style="font-size:small"><span style="font-weight:bold">void</span></span><span style="font-size:small"> </span><span style="font-size:small">opB</span><span style="font-size:small">();</span><span style="font-size:small">
</span><span style="font-size:small">  };</span><span style="font-size:small">
</span><span style="font-size:small">};</span></div><p>A reference to an object with interface <span style="font-family:monospace">B</span> will
normally contain the repository id &#X2018;<span style="font-family:monospace">IDL:M2/B:1.0</span>&#X2019;<sup><a id="text6" href="#note6">1</a></sup>. It is also permitted to have an empty
repository id, or the id &#X2018;<span style="font-family:monospace">IDL:M1/A:1.0</span>&#X2019;.
&#X2018;<span style="font-family:monospace">IDL:M1/A:1.0</span>&#X2019; is unlikely unless the server is being
deliberately obtuse.</p><p>Whenever omniORBpy receives an object reference from
somewhere&#X2014;either as a return value or as an operation argument&#X2014;it
has a particular <span style="font-style:italic">target</span> interface in mind, which it compares
with the repository id it has received. A target of base
<span style="font-family:monospace">CORBA::Object</span> is just one (common) case. For example, in the
following IDL:</p><div class="lstlisting"><span style="font-size:small"><span style="font-style:italic"><span style="font-size:small">// c.idl</span></span></span><span style="font-size:small">
</span><span style="font-size:small"><span style="font-weight:bold">#include</span></span><span style="font-size:small"> </span><span style="font-size:small"><span style="font-size:small">"a.idl"</span></span><span style="font-size:small">
</span><span style="font-size:small"><span style="font-weight:bold">module</span></span><span style="font-size:small"> </span><span style="font-size:small">M3</span><span style="font-size:small"> {</span><span style="font-size:small">
</span><span style="font-size:small">  </span><span style="font-size:small"><span style="font-weight:bold">interface</span></span><span style="font-size:small"> </span><span style="font-size:small">C</span><span style="font-size:small"> {</span><span style="font-size:small">
</span><span style="font-size:small">    </span><span style="font-size:small"><span style="font-weight:bold">Object</span></span><span style="font-size:small"> </span><span style="font-size:small">getObj</span><span style="font-size:small">();</span><span style="font-size:small">
</span><span style="font-size:small">    </span><span style="font-size:small">M1</span><span style="font-size:small">::</span><span style="font-size:small">A</span><span style="font-size:small">  </span><span style="font-size:small">getA</span><span style="font-size:small">();</span><span style="font-size:small">
</span><span style="font-size:small">  };</span><span style="font-size:small">
</span><span style="font-size:small">};</span></div><p>the target interface for <span style="font-family:monospace">getObj</span>&#X2019;s return value is
<span style="font-family:monospace">CORBA::Object</span>; the target interface for <span style="font-family:monospace">getA</span>&#X2019;s return
value is <span style="font-family:monospace">M1::A</span>.</p><p>omniORBpy uses the result of comparing the received and target
repository ids to determine the type of the object reference it
creates. The object reference has either the type of the received
reference, or the target type, according to this table:</p><div class="center">
<table border=1  style="border-spacing:0;" class="cellpadding1"><tr><td style="text-align:left;border:solid 1px;white-space:nowrap"  colspan=2><span style="font-weight:bold">Case</span></td><td style="vertical-align:top;text-align:left;border:solid 1px;white-space:nowrap" > <span style="font-weight:bold">Objref Type</span></td></tr>
<tr><td style="vertical-align:top;text-align:left;border:solid 1px;white-space:nowrap" >
1.</td><td style="vertical-align:top;text-align:left;border:solid 1px;" >The received id is the same as the target id</td><td style="vertical-align:top;text-align:left;border:solid 1px;white-space:nowrap" >received</td></tr>
<tr><td style="vertical-align:top;text-align:left;border:solid 1px;white-space:nowrap" >
2.</td><td style="vertical-align:top;text-align:left;border:solid 1px;" >The received id is not the same as the target id, but the
ORB knows that the received interface is derived from
the target interface</td><td style="vertical-align:top;text-align:left;border:solid 1px;white-space:nowrap" >received</td></tr>
<tr><td style="vertical-align:top;text-align:left;border:solid 1px;white-space:nowrap" >
3.</td><td style="vertical-align:top;text-align:left;border:solid 1px;" >The received id is unknown to the ORB</td><td style="vertical-align:top;text-align:left;border:solid 1px;white-space:nowrap" >target</td></tr>
<tr><td style="vertical-align:top;text-align:left;border:solid 1px;white-space:nowrap" >
4.</td><td style="vertical-align:top;text-align:left;border:solid 1px;" >The received id is not the same as the target id, and the
ORB knows that the received interface is <em>not</em>
derived from the target interface</td><td style="vertical-align:top;text-align:left;border:solid 1px;white-space:nowrap" >target </td></tr>
</table>
</div><p>Cases 1 and 2 are the most common. Case 2 explains why it is not
necessary to narrow the result of calling
<span style="font-family:monospace">resolve_initial_references("RootPOA")</span>: the return is always
of the known type <span style="font-family:monospace">PortableServer.POA</span>, which is derived from the
target type of <span style="font-family:monospace">CORBA.Object</span>.</p><p>Case 3 is also quite common. Suppose a client knows about IDL modules
<span style="font-family:monospace">M1</span> and <span style="font-family:monospace">M3</span> from above, but not module <span style="font-family:monospace">M2</span>.
When it calls <span style="font-family:monospace">getA()</span> on an instance of <span style="font-family:monospace">M3::C</span>, the return
value may validly be of type <span style="font-family:monospace">M2::B</span>, which it does not know. By
creating an object reference of type <span style="font-family:monospace">M1::A</span> in this case, the
client is still able to call the object&#X2019;s <span style="font-family:monospace">opA()</span> operation. On the
other hand, if <span style="font-family:monospace">getObj()</span> returns an object of type <span style="font-family:monospace">M2::B</span>, the
ORB will create a reference to base <span style="font-family:monospace">CORBA::Object</span>, since that
is the target type.</p><p>Note that the ORB <em>never</em> rejects an object reference due to it
having the wrong type. Even if it knows that the received id is not
derived from the target interface (case 4), it might be the case that
the object actually has a more derived interface, which is derived
from both the type it is claiming to be <em>and</em> the target type.
That is, of course, extremely unlikely.</p><p>In cases 3 and 4, the ORB confirms the type of the object by calling
<span style="font-family:monospace">_is_a()</span> just before the first invocation on the object. If it
turns out that the object is not of the right type after all, the
<span style="font-family:monospace">CORBA.INV_OBJREF</span> exception is raised. The alternative to this
approach would be to check the types of object references when they
were received, rather than waiting until the first invocation. That
would be inefficient, however, since it is quite possible that a
received object reference will never be used. It may also cause
objects to be activated earlier than expected.</p><p>In summary, whenever your code receives an object reference, you
should bear in mind what omniORBpy&#X2019;s idea of the target type is. You
must not assume that the ORB will always correctly figure out a more
derived type than the target. One consequence of this is that you must
always narrow a plain <span style="font-family:monospace">CORBA::Object</span> to a more specific type
before invoking on it<sup><a id="text7" href="#note7">2</a></sup>. You
<em>can</em> assume that the object reference you receive is of the
target type, or something derived from it, although the object it
refers to may turn out to be invalid. The fact that omniORBpy often
<em>is</em> able figure out a more derived type than the target is only
useful when using the Python interactive command line.</p>
<h2 id="sec36" class="section">3.2&#XA0;&#XA0;Support for Any values</h2>
<p>In statically typed languages, such as C++, Anys can only be used with
built-in types and IDL-declared types for which stubs have been
generated. If, for example, a C++ program receives an Any containing a
struct for which it does not have static knowledge, it cannot easily
extract the struct contents. The only solution is to use the
inconvenient DynAny interface.</p><p>Since Python is a dynamically typed language, it does not have this
difficulty. When omniORBpy receives an Any containing types it does
not know, it is able to create new Python types which behave exactly
as if there were statically generated stubs available. Note that this
behaviour is not required by the Python mapping specification, so
other Python ORBs may not be so accommodating.</p><p>The equivalent of DynAny creation can be achieved by dynamically
writing and importing new IDL, as described in
section&#XA0;<a href="omniORBpy004.html#sec%3AimportIDL">4.9</a>.</p><p>There is, however, a minor fly in the ointment when it comes to
receiving Anys. When an Any is transmitted, it is sent as a TypeCode
followed by the actual value. Normally, the TypeCodes for entities
with names&#X2014;members of structs, for example&#X2014;contain those names as
strings. That permits omniORBpy to create types with the corresponding
names. Unfortunately, the GIOP specification permits TypeCodes to be
sent with empty strings where the names would normally be. In this
situation, the types which omniORBpy creates cannot be given the
correct names. The contents of all types except structs and exceptions
can be accessed without having to know their names, through the
standard interfaces. Unknown structs, exceptions and valuetypes
received by omniORBpy have an attribute named &#X2018;<span style="font-family:monospace">_values</span>&#X2019; which
contains a sequence of the member values. This attribute is omniORBpy
specific.</p><p>Similarly, TypeCodes for constructed types such as structs and unions
normally contain the repository ids of those types. This means that
omniORBpy can use types statically declared in the stubs when they are
available. Once again, the specification permits the repository id
strings to be empty<sup><a id="text8" href="#note8">3</a></sup>. This means that even if stubs for a type
received in an Any are available, it may not be able to create a
Python value with the right type. For example, with a struct
definition such as:</p><div class="lstlisting"><span style="font-size:small"><span style="font-weight:bold">module</span></span><span style="font-size:small"> </span><span style="font-size:small">M</span><span style="font-size:small"> {</span><span style="font-size:small">
</span><span style="font-size:small">  </span><span style="font-size:small"><span style="font-weight:bold">struct</span></span><span style="font-size:small"> </span><span style="font-size:small">S</span><span style="font-size:small"> {</span><span style="font-size:small">
</span><span style="font-size:small">    </span><span style="font-size:small"><span style="font-weight:bold">string</span></span><span style="font-size:small"> </span><span style="font-size:small">str</span><span style="font-size:small">;</span><span style="font-size:small">
</span><span style="font-size:small">    </span><span style="font-size:small"><span style="font-weight:bold">long</span></span><span style="font-size:small">   </span><span style="font-size:small">l</span><span style="font-size:small">;</span><span style="font-size:small">
</span><span style="font-size:small">  };</span><span style="font-size:small">
</span><span style="font-size:small">};</span></div><p>The transmitted TypeCode for <span style="font-family:monospace">M::S</span> may contain only
the information that it is a structure containing a string followed by
a long, not that it is type <span style="font-family:monospace">M::S</span>, or what the member names are.</p><p>To cope with this situation, omniORBpy has an extension to the
standard interface which allows you to <span style="font-style:italic">coerce</span> an Any value to a
known type. Calling an Any&#X2019;s <span style="font-family:monospace">value()</span> method with a TypeCode
argument returns either a value of the requested type, or <span style="font-family:monospace">None</span>
if the requested TypeCode is not <span style="font-style:italic">equivalent</span> to the Any&#X2019;s
TypeCode. The following code is guaranteed to be safe, but is not
standard:</p><div class="lstlisting"><span style="font-size:small">a</span><span style="font-size:small"> = </span><span style="font-size:small"><span style="font-style:italic"><span style="font-size:small"># Acquire an Any from somewhere</span></span></span><span style="font-size:small">
</span><span style="font-size:small">v</span><span style="font-size:small"> = </span><span style="font-size:small">a</span><span style="font-size:small">.</span><span style="font-size:small">value</span><span style="font-size:small">(</span><span style="font-size:small">CORBA</span><span style="font-size:small">.</span><span style="font-size:small">TypeCode</span><span style="font-size:small">(</span><span style="font-size:small">CORBA</span><span style="font-size:small">.</span><span style="font-size:small">id</span><span style="font-size:small">(</span><span style="font-size:small">M</span><span style="font-size:small">.</span><span style="font-size:small">S</span><span style="font-size:small">)))</span><span style="font-size:small">
</span><span style="font-size:small"><span style="font-weight:bold">if</span></span><span style="font-size:small"> </span><span style="font-size:small">v</span><span style="font-size:small"> </span><span style="font-size:small"><span style="font-weight:bold">is</span></span><span style="font-size:small"> </span><span style="font-size:small"><span style="font-weight:bold">not</span></span><span style="font-size:small"> </span><span style="font-size:small">None</span><span style="font-size:small">:</span><span style="font-size:small">
</span><span style="font-size:small">    </span><span style="font-size:small"><span style="font-weight:bold">print</span></span><span style="font-size:small"> </span><span style="font-size:small">v</span><span style="font-size:small">.</span><span style="font-size:small">str</span><span style="font-size:small">
</span><span style="font-size:small"><span style="font-weight:bold">else</span></span><span style="font-size:small">:</span><span style="font-size:small">
</span><span style="font-size:small">    </span><span style="font-size:small"><span style="font-weight:bold">print</span></span><span style="font-size:small"> </span><span style="font-size:small"><span style="font-size:small">"The Any does not contain a value compatible with M::S."</span></span></div>
<h3 id="sec37" class="subsection">3.2.1&#XA0;&#XA0;Any helper module</h3>
<p>omniORBpy provides an alternative, non-standard way of constructing
and deconstructing Anys that is often more convenient to use in Python
programs. It uses Python&#X2019;s own dynamic typing to infer the TypeCodes
to use. The <span style="font-family:monospace">omniORB.any</span> module contains two functions,
<span style="font-family:monospace">to_any()</span> and <span style="font-family:monospace">from_any()</span>.</p><p><span style="font-family:monospace">to_any()</span> takes a Python object and tries to return it inside an
Any. It uses the following rules:</p><ul class="itemize"><li class="li-itemize">
Python strings are represented as CORBA strings.
</li><li class="li-itemize">Python unicode objects are represented as CORBA wstrings.
</li><li class="li-itemize">Python integers are represented as CORBA longs.</li><li class="li-itemize">Python long integers are represented as a CORBA integer type
taken from long, unsigned long, long long, unsigned long, depending on
what size type the Python long integer will fit in. If the value is
too large for any of these, <span style="font-family:monospace">CORBA.BAD_PARAM</span> is raised.</li><li class="li-itemize">Python lists and tuples of the types above are represented as
sequences of the corresponding CORBA types.</li><li class="li-itemize">Python lists and tuples of mixed types are represented as
sequences of Anys.</li><li class="li-itemize">Python dictionaries with string keys are represented as CORBA
structs, using the dictionary keys as the member names, and the
types of the dictionary values as the member types.</li><li class="li-itemize">Instances of CORBA types (structs, unions, enums, etc.)
generated by the IDL compiler are represented as themselves.
</li></ul><p>All other Python types result in a <span style="font-family:monospace">CORBA.BAD_PARAM</span> exception.</p><p>The <span style="font-family:monospace">from_any()</span> function works in reverse. It takes an Any as its
argument and extracts its contents using the same rules as
<span style="font-family:monospace">to_any()</span>. By default, CORBA structs are extracted to dictionaries;
if the optional <span style="font-family:monospace">keep_structs</span> argument is set true, they are
instead left as instances of the CORBA struct classes.</p>
<h2 id="sec38" class="section">3.3&#XA0;&#XA0;Interface Repository stubs</h2>
<p>
<a id="sec:ifrstubs"></a></p><p>The Interface Repository interfaces are declared in IDL module
<span style="font-family:monospace">CORBA</span> so, according to the Python mapping, the stubs for them
should appear in the Python <span style="font-family:monospace">CORBA</span> module, along with all the
other CORBA definitions. However, since the stubs are extremely large,
omniORBpy does not include them by default. To do so would
unnecessarily increase the memory footprint and start-up time.</p><p>The Interface Repository stubs are automatically included if you
define the <span style="font-family:monospace">OMNIORBPY_IMPORT_IR_STUBS</span> environment variable.
Alternatively, you can import the stubs at run-time by calling the
<span style="font-family:monospace">omniORB.importIRStubs()</span> function. In both cases, the stubs become
available in the Python <span style="font-family:monospace">CORBA</span> module.</p>
<h2 id="sec39" class="section">3.4&#XA0;&#XA0;IDL attributes</h2>
<p>
<a id="sec:attributes"></a></p><p>The Python language mapping says that IDL attributes map to methods
with names prefixed <span style="font-family:monospace">_get_</span> and <span style="font-family:monospace">_set_</span>. omniORBpy
adheres to this standard mapping, but additionally supports access
using properties:</p><div class="lstlisting"><span style="font-size:small"><span style="font-weight:bold">module</span></span><span style="font-size:small"> </span><span style="font-size:small">M</span><span style="font-size:small"> {</span><span style="font-size:small">
</span><span style="font-size:small">  </span><span style="font-size:small"><span style="font-weight:bold">interface</span></span><span style="font-size:small"> </span><span style="font-size:small">Example</span><span style="font-size:small"> {</span><span style="font-size:small">
</span><span style="font-size:small">    </span><span style="font-size:small"><span style="font-weight:bold">attribute</span></span><span style="font-size:small"> </span><span style="font-size:small"><span style="font-weight:bold">string</span></span><span style="font-size:small"> </span><span style="font-size:small">attr1</span><span style="font-size:small">;</span><span style="font-size:small">
</span><span style="font-size:small">    </span><span style="font-size:small"><span style="font-weight:bold">readonly</span></span><span style="font-size:small"> </span><span style="font-size:small"><span style="font-weight:bold">attribute</span></span><span style="font-size:small"> </span><span style="font-size:small"><span style="font-weight:bold">long</span></span><span style="font-size:small"> </span><span style="font-size:small">attr2</span><span style="font-size:small">;</span><span style="font-size:small">
</span><span style="font-size:small">  };</span><span style="font-size:small">
</span><span style="font-size:small">};</span></div><div class="lstlisting"><span style="font-size:small">obj</span><span style="font-size:small"> = </span><span style="font-size:small"><span style="font-style:italic"><span style="font-size:small"># an M::Example object reference</span></span></span><span style="font-size:small">
</span><span style="font-size:small">obj</span><span style="font-size:small">.</span><span style="font-size:small">attr1</span><span style="font-size:small"> = </span><span style="font-size:small"><span style="font-size:small">"Hello"</span></span><span style="font-size:small">
</span><span style="font-size:small"><span style="font-weight:bold">print</span></span><span style="font-size:small"> </span><span style="font-size:small">obj</span><span style="font-size:small">.</span><span style="font-size:small">attr2</span></div><p>Servant classes can similarly provide attribute values using simple
Python object attributes or properties. When invoking an attribute
getter or setter, omniORBpy first looks for a method with the standard
<span style="font-family:monospace">_get_</span> or <span style="font-family:monospace">_set_</span> name. If that is not found, a simple
attribute lookup is performed. This is therefore a complete
implementation of the <span style="font-family:monospace">M::Example</span> interface:</p><div class="lstlisting"><span style="font-size:small"><span style="font-weight:bold">class</span></span><span style="font-size:small"> </span><span style="font-size:small">Example_i</span><span style="font-size:small"> (</span><span style="font-size:small">M__POA</span><span style="font-size:small">.</span><span style="font-size:small">Example</span><span style="font-size:small">):</span><span style="font-size:small">
</span><span style="font-size:small">    </span><span style="font-size:small"><span style="font-weight:bold">def</span></span><span style="font-size:small"> </span><span style="font-size:small">__init__</span><span style="font-size:small">(</span><span style="font-size:small">self</span><span style="font-size:small">):</span><span style="font-size:small">
</span><span style="font-size:small">        </span><span style="font-size:small">self</span><span style="font-size:small">.</span><span style="font-size:small">attr1</span><span style="font-size:small"> = </span><span style="font-size:small"><span style="font-size:small">"Test"</span></span><span style="font-size:small">
</span><span style="font-size:small">        </span><span style="font-size:small">self</span><span style="font-size:small">.</span><span style="font-size:small">attr2</span><span style="font-size:small"> = 1234</span></div>
<hr class="footnoterule"><dl class="thefootnotes"><dt class="dt-thefootnotes">
<a id="note6" href="#text6">1</a></dt><dd class="dd-thefootnotes"><div class="footnotetext">It
is possible to change the repository id strings associated with
particular interfaces using the <span style="font-family:monospace">ID</span>, <span style="font-family:monospace">version</span> and
<span style="font-family:monospace">prefix</span> pragmas.</div></dd><dt class="dt-thefootnotes"><a id="note7" href="#text7">2</a></dt><dd class="dd-thefootnotes"><div class="footnotetext">Unless you are invoking pseudo
operations like <span style="font-family:monospace">_is_a()</span> and <span style="font-family:monospace">_non_existent()</span>.</div></dd><dt class="dt-thefootnotes"><a id="note8" href="#text8">3</a></dt><dd class="dd-thefootnotes"><div class="footnotetext">The use of empty repository id strings is
deprecated as of GIOP 1.2.</div></dd></dl>
<hr>
<a href="omniORBpy002.html"><img src="previous_motif.svg" alt="Previous"></a>
<a href="index.html"><img src="contents_motif.svg" alt="Up"></a>
<a href="omniORBpy004.html"><img src="next_motif.svg" alt="Next"></a>
</body>
</html>
